Security in Active Networks

The desire for exible networking services has given rise to the concept of \active networks." Active networks provide a general framework for designing and implementing network-embedded services, typically by means of a programmable network infrastructure. A programmable network infrastructure creates signi cant new challenges for securing the network infrastructure. This paper begins with an overview of active networking. It then moves to security issues, beginning with a threat model for active networking, moving through an enumeration of the challenges for system designers, and ending with a survey of approaches for meeting those challenges. The Secure Active Networking Environment (SANE) realizes many of these approaches; an implementation exists and provides acceptable performance for even the most aggressive active networking proposals such as active packets (sometimes called \capsules"). We close the paper with a discussion of open problems and an attempt to prioritize them. 1 What is Active Networking ? In networking architectures a design choice can be made between: 1. Restricting the actions of the network infrastructure to transport, and 2. easing those restrictions to permit on-they customization of the network infrastructure. The data-transport model, which has been successfully applied in the IP Internet and other networks, is called passive networking since the infrastructure (e.g., IP routers) is mostly indi erent to the packets passing through, and their actions (forwarding and routing) cannot be directly in uenced by users. This is not to say that the switches do not perform complex computations as a result of receiving or forwarding a packet. Rather, the nature of these computations cannot dynamically change beyond the fairly basic con guration options provided by the manufacturer of the switch. In contrast, active networking allows network-embedded functionality other than transport. For current systems, this functionality ranges from WWW proxy caches, multicasting [Dee89] and RSVP [BZB97] to rewalls. Since each of these independently designed and supported functions could be carried out as an application of a more general infrastructure, the architecture of such active infrastructures is now being investigated aggressively. The basic principle employed is the use of programmability, as this allows many applications to be created, including those not foreseen by the designers of the switch. There are a number of forms this programmability can take, including treating each packet as a program (active packets or \capsules") and programming or reprogramming network elements on-they with select packets. Note that the latter approach subsumes the former, as a program may be loaded that treats all subsequent packets as programs. 1.1 Why is Active Network Security Interesting? From a security perspective, a large scale infrastructure with user access to programming capabilities, even if restricted, creates a wide variety of di cult challenges. Most directly, since the basis of security is controlled access to resources, the increased complexity of the managed resources makes securing them much more di cult. Since \security" is best thought of as a mapping between a policy and a set of predicates maintained through actions, the policy must be more complex than, in as much as they exist, equivalent policies of present-day networks, resulting in an explosion in the set of predicates. For example, the ability to load a new queuing discipline may be attractive from a resource control perspective, but if the queuing discipline can replace that of an existing user, the replacement policy must be speci ed, and its implementation carefully controlled through one or more policy enforcement mechanisms. Additionally, such a scenario forces the de nition of principals and objects with which policies are associated. When compared with the policy at a basic IP router (no principals, datagram delivery guarantees, FIFO queuing, etc.) it can be seen why securing active networks is di cult. 1.2 Virtual and Real Resources As the role of active networking elements is to store, compute and forward, the managed resources are those required to store packets, operate on them, and forward them to other elements. The resources provided to various principals at any instant cannot exceed the real resources (e.g., output port bandwidth) available at that instant. This emphasis on real resources and time implies that a conventional 3-tuple for an access control list (ACL) is inadequate. To provide controlled access to real resources, with real time constraints, a fourth element to represent duration (either absolute or periodic) must be added, giving . This remains an ACL, but is not \virtualized" by leaving time unspeci ed and making \eventual" access acceptable. We should point out that this new element in the ACL can be encoded as part of the access eld. Similarly, we need not use an actual ACL, but we may use mechanisms that can be expressed in terms of ACLS and are better-suited for distributed systems.